Warp wrote:
> 
> Nekar Xenos <j-p### [at] citywalkcoza> wrote:
> : A friend of mine is all excited about Flamingo that he says does radiosity
> : faster and better than Pov.
> 
>   The global lighting code of POV-Ray has still way to go, as it still has
> some unknown problems (bugs?). AFAIK POV-Ray 3.5 will have basically the same
> radiosity code as MegaPov has.
>   In many scenes it works like a charm, very fast and the result is excellent.
> However, it's quite usual that you just don't get it working in your
> specific scene (either it's too dim or too bright or has annoying artifacts,
> specially near corners; it also has this annoying tendency of working in
> the way that if you set low quality you get good but unrealistic illumination
> (eg. no darkening in corners) and if you set high quality you get better
> illumination but annoying artifacts in corners). These problems might be
> caused by wrong or buggy code. Perhaps a total rewrite could be necessary
> in order to get rid of the problems (it seems that currently no-one knows
> where the problems are in the radiosity code)?

If you imagine radiosity as being like shading being applied to the
scene with a brush and diluted black ink, it becomes fairly easy to
understand.. well, for me anyway. (This analogy is kind of a butchery of
the way radiosity ACTUALLY works, but it's a fair description of its
effect on a scene.)

If you use a high error_bound, it's as if you were using a large brush,
or a sponge, to paint the shading on. This gives good overall lighting,
like a kind of "smart" ambient, but doesn't produce sharp shadows. It
also doesn't produce obvious artifacts, simply because the artifacts are
generally too large to be obvious. (Try lighting a "room" with
radiosity, using a high error_bound and a really low count. There should
be very noticible circles of varying brightness on the walls.)

If you use a low error_bound, the effect is that of using a small brush
to paint in the shadows with tiny strokes. Your lighting takes on a much
more noisy, grainy look - including artifacts in the corners, where
shadows "build up" - but shadow outlines are much more clearly defined.

For this analogy, imagine count as a measure of how thorough you are in
applying the ink with your brush. A low count represents strong ink,
applied quickly and sloppily. As you raise the count, you make more
strokes, using thinner ink, and the shadows take on more and more of a
"blended" look until finally they become smooth.

(The other parameters also have an effect on radiosity, of course, but
none of them are particularly important to this analogy. Many of them
are similar to count.)

Now, if you, a human being, were to attempt to shade a picture this way,
you would probably make an effort to put new splotches in the lighter
parts, so that even if the shading were grainy-looking, it would at
least be an even sort of graininess. But the computer makes no such
considerations, and when you imagine the result of randomly-placed
shading splotches, the reason for the artifacts becomes obvious...

Judging from old radiosity pics and the way official POV radiosity
works, I'd guess that whoever wrote the code never expected radiosity to
be used the way it's often used today. So it's not that the code is
buggy per se, it's just poorly-optimized for detail work, and what we
probably need is a smarter algorithm.

-Xplo

Post a reply to this message